Riot GamesでのAWS Device Farmを使った大規模テスト運用事例とサービスアップデート情報 #AWSreinvent

Improve your mobile and web app quality using AWS Device Farm のセッションに参加したので内容をまとめます。

セッション概要

• セッション ID: FWM202
• タイトル：Improve your mobile and web app quality using AWS Device Farm
• スピーカー：Sam Patzer/AWS, Alex Lynchosky/ Riot Games, Nikhil Dabhade/ AWS
• レベル：200 - Intermediate

本セッションでは、AWS Device Farm を利用し、実デバイス上でテストを大規模に実行することで、モバイルアプリや Web アプリの品質を向上させる方法をご紹介します。モバイルアプリのテストプロセスを合理化し、モバイルゲームと SDK の品質を向上させ、クラウド上の実デバイス上で自動テストと手動テストを実行し、問題を迅速に特定して修正し、より頻繁にアップデートをリリースするために、Device Farm をどのように使用しているかについて、大手ゲーム開発者およびパブリッシャーである Riot Games 社から話を聞きます。Riot 社が、新しくリリースされたプライベートデバイスへの VPC 接続のサポートを利用して、自社の VPC 内から AWS Device Farm に安全にアクセスし、テストデータのプライベート性と安全性を確保する方法をお聞きください。

What is Device Farm?

AWS Device Farm は Web とモバイルアプリの動作確認、デバッグ、テストを行う DevOps ツールです。事前のプロビジョニングは不要でワンクリックで利用開始でき、必要に応じてスケーリング可能で複数のテストを非同期的に同時に実行することができます。

Device Farm ではクラウドの裏側に本物のデバイスが存在します。ということは DevOps チームは本物のデバイスを使って異なる数千のバージョン、デバイスでのテストを効率よく実施することができます。例えば iOS の新しいパッチバージョンがリリースされた際に既存または古いバージョンのアプリが問題なく動作するかを本物のデバイスで確認することができるのです。

世の中のほとんどのアプリは最新の OS バージョン以外に３、４つ程の古いバージョンの OS もサポートしなくてはならないケースがほとんどです。つまり最新の OS がリリースされた場合、新しい OS 環境以外に古いいくつかの環境での動作も同時に確認する必要があります。

もし手元にあるデバイスの OS アップデートボタンを間違って押してしまい、さらにそのデバイスが社内唯一の古い OS バージョンのデバイスだった場合、我々はどうやって前のバージョンのデバイスを手に入れるか頭を悩ませる必要があります。

Device Farm を使う場合、OS のバージョンやアプリのバージョンをテスト前に指定することができるので上のような事象に苦しむ必要はなくなります。テスト後はデバイスの状態をクリーンアップできますし、自動的に様々な大きさのデバイスでテストの実施を行いアニメーションがきちんと動作するか、コンテンツが画面にフィットしているか、CSS の崩れがないかなどを調査することが可能です。

テストで行ったアクションのログは全てアーティファクトに保持され、異常があった場合のデバッグや開発チームとのやりとりに利用できます。

我々開発者を悩ませる要因は OS のバージョンだけではありません、Android には数千のデバイスが存在し製造元が異なる Android のバージョンをデバイスにインストールしている場合があります。

また、最近の例だと Apple のデバイスにベゼルが追加されましたよね、ユーザー目線ではクールなアップデートですが開発者から見ると大きな頭痛の種です。既存のアプリの要素がこのベゼルに被っていないか、ベゼルの有無に関わらずアプリの全ての要素が動作するのかを早急に確認する必要があります。

よくある質問で、デバイスでの動作確認のためのテストを書いていないので私たちのチームでは Device Farm を使えないのではないかという相談をよくされます。

Device Farm には Fazz が組み込まれているのでテストケースを書いていない場合、ランダムに要素をクリックしたり要素が画面にフィットしてくれるかを自動で検出してくれます。その際に CPU の利用メトリクスやメモリ利用状況、スレッドの利用状況も同時にキャプチャしてくれるので普段ユーザーが行わないような操作を実デバイス上で行った際のクラッシュの検出や不要なスレッドの利用などを発見できる可能性が上がります。

Macbook のエミュレータを使う場合、実際のデバイスより大きなメモリ量のデバイスで動かしているが故にクラッシュしなかったケースも実機でのテストによりクラッシュが再現するケースもあります。

Riot Games について

Riot Games、当時は末尾の s がなく Riot Game という名前でしたが、Riot Game は 2006 年に 最初のゲーム、League of Legend をリリースしました。その後 e-sports 界を代表する大会、LoL E-Sport が発足し、今年の番組の同時接続数は 600 万にも上りました。

さらに 2009 年にはモバイルで動作する LoL、League of Legend WildRift がリリースされ、この辺りから Device Farm が少しづつ関係ある話になります。その後リリースされたモバイルゲーム、TEAMFIGHT TACTICS では Device Farm がかなり活躍しました。

Riot Games のプロダクトテストの内容

我々のプロダクトのコンテキストではテストはこの 2 種類に分けられます。ゲームプレイテストと動作テストです(Quinn が誰かを知らない人は知らないままでも大丈夫です、仮に知っていてもこのスライドが意味不明なことには変わりないでしょう)。

ゲームテストと聞いた時に考えられるテストの例として、このゲームは人間がプレイして楽しいか、ゲームバランスは最適か、デザインされたゲームキャラクターは操作して楽しいものか、といったものが挙げられます。このようなテストは全てゲームプレイテストに割り当てられ、人間が行います。

これらのテストとは別にテクニカルな面を主に見る動作テストがありますが、まずはゲームプレイテストについて説明します。

今年、2023 年の EVO で私たちは Project L のゲームプレイデモを初めて公開しました。その際にゲームをプレイしたプレイヤーからたくさんの良いフィードバックを得られました。例えば、斧を振り下ろした時の感覚が最高、キャラのデザインやグラフィックがとても良い、等です。これらのテストはテストプレイヤーや QA 担当者などの人間によって厳しく行われます。

人間たちによってこのゲームはプレイして楽しいものであることが証明されました。ではそれ以外の機能面はどうでしょうか。ここで先ほど少しご紹介した動作テストの話になります。

機能テストではゲームを動作する環境別のパフォーマンスに焦点を当てます。例えば、このゲームを起動した際にデバイスはオーバーヒートするのか？このデバイスにあてがわれているスレッドの数でゲームをプレイした場合全ての機能が問題なく動作するのか？等です。開発チームはゲームがプレイヤーの異なる数千のデバイスでどのように動作するかを把握しておく必要があるのです。

以前我々は Android の新しいバージョンがリリースされるたびに QA チームにそのバージョンの Andoroid がインストールされたデバイスを渡してテストを依頼していました。QA チームは渡されたデバイスを PC に接続してテストを実行するのですが、そのすぐ後に Android の次のバージョンがリリースされました。さらに今度は iOS の新しいバージョンがリリースされ、QA デスクはすぐにパンクし、我々は QA チームを増員しました。この様子から分かるように当時 QA デスクのスケーリングは人間のタスクで、Riot 社全体の大きな問題でした。

なぜならどのタイトルかに関わらず全てのチームが同じ問題を抱えていたからです。デバイスは豊富にありましたが、異なるバージョンのゲームブランチにデバイスをつなげてテストを行いバグがあったら調査するこのやり方はスケーラブルではなくさらにそれぞれのチームは独自で違うやり方でテストを行なっていました。

この問題をどう解決するか？ 我々はテスティングプラットフォームを一つに集約することにしました。

テストプラットフォームを一元化することでどこかのチームの可哀想な QA 担当者のデスクにデバイスが積まれることがなくなりました。

我々の求めたソリューションは、API リクエストでテストを開始し、テスト結果やログを１箇所に保存できるようなシステムでした。

Riot Games での Device Farm 運用事例

先ほど Riot 内の全てのゲーム開発チームがこのテストプラットフォームを利用するようにしたいとお話ししましたが、具体的にどうやって全てのチームの開発者がこのシステムにアクセスできるか確認することができるでしょうか。

まず我々はこのテストプラットフォームを API からアクセスできるようにしました。前段に API Gateway を設置し、CI/CD パイプラインや自動テストツールから、または QA 担当者やゲーム開発者が手動でテストを実行できるようにしました。

次にリクエストを処理する ワークフローリクエスト Lambda を設置し、API Gateway からのリクエストが順番に処理されるようにリクエストをキューに渡します。

Lambda では 複数の Dynamo DB に問い合わせ、リクエストに基づいたデバイスがクリーンな状態で利用可能であるかを確認します。

ここで我々が利用している 2 種類の Device Farm についてご説明します。１つ目の Device Farm は我々が以前まで利用していた膨大な量の、かつて可哀想な QA 担当者のデスクに積まれていた Riot が所有するデバイスで構成された オンプレミスのDevice Farm。もう一つは、我々のテストに利用しているほとんどのデバイスが保持されているクラウドベースの AWS の Device Farm です。

我々は複数の理由からクラウドベースの Device Farm の利用を好みます。オンプレミスのデバイスを使う場合、社内でデバイスにまつわる様々なタスクが発生します。例えば物理的な損傷や破損。コードが抜けてしまっていないかの確認といったマニュアルで行わないといけないタスクが多く、とてもスケーラブルとは言えません。クラウドベースの Device Farm を利用する場合このような心配事がなくなります。

最初の Lambda でリクエストされたデバイスがクリーンなステートで利用可能である場合、次の Lambda に処理が移行し、オンプレミスの Device Farm を利用するか、クラウドベースの　 AWS の Device Farm を利用するかを判断し、テストを実行します。

テストが実行されている間、実行中、完了、アーティファクト作成中などのテストステート別にイベントが Event Bridge に送信され、これらの情報は最終的に Apache Kafka へストリーミングされます。

なぜ Riot が Device Farm を選んだか

なぜ AWS Device Farm が Riot Games のテストツールとして優れているかという点については色々理由はあります。Device Farm を導入した直後は内部からの多くの質問が寄せられました。例えば、どうやって実機でテストを実行するのか、Device Farm 内で具体的にどのようにゲームがテストされるのか？テスト結果はどこで見れるのか？この環境はセキュアなのか？などです。

具体的にどのように Device Farm 内のデバイスでゲームを実行するかというと、実際にはテスト用のビルド、もっとわかりやすくいうとテストしたい部分のみのコードが含まれたビルドを作成して appium というテストツールを使ってテストを実行します。appium はネイティブアプリ用のテストフレームワークで、パラメータを指定してアプリを実行することができます。我々の場合はこのマップでこのキャラクターを使ってこのシナリオをプレイする、といったパラメータを渡します。

Device Farm と appium を使う場合、非同期的に複数のテストを実行することが可能です。今まで QA エンジニアが一つづつ異なるデバイスで同じシナリオを実行していたのが今では 50 の異なるデバイスでの同様のテストを非同期的に同時に行うことができるようになりました。

次にどうやってテスト可能なデバイスを知ることができるのか？という質問がありました。全てのデバイスの情報はクエリ可能なデータベースに保持されており、それぞれのデバイスの現在の状況やスペックが確認可能で Device Farm のダッシュボードからフィルタリングすることができます。

最後に、ゲーム開発者が絶対に確認しておきたいことがありました。このテストプラットフォームは開発中のゲームサーバーと接続できるのか？ということです。パブリックでない環境でゲームをテストできるのか？という問いに対して AWS Device Farm の VPC サポートが回答になります。

VPC サポートを利用すれば開発用のクラウド上またはオンプレミスのゲームサーバーをそのまま VPC 環境に接続することができます。オンプレミスの場合はそのまま VPC へ接続すればいいのですが、クラウド上で開発している場合はどうでしょう。

Device Farm のネットワーク構成は以下です。

まずは Riot の AWS アカウントがあります。Device Farm の環境もここにあります。ここからオンプレミスの Device Farm を利用するかクラウドベースの Device Farm を利用するかの分岐があり、クラウドを利用する場合それぞれのデバイス別に AWS アカウントが存在し、VPC 環境でテストを行う場合、この分けられたアカウント内の VPC 内で指定したデバイスが動作します。

こうすることでまだリリースされていないゲームのテストをプライベートな環境で安全にテストできるというわけです。

以下はまとめです。

• Q. 私たちのゲームもテストできる？どうやって？
• A. できます。具体的に appium を利用してコマンドでパラメーターを渡してゲームを動かしてテストします。テストしたいゲームがコマンド入力をサポートしてさえいればテスト可能です。

• Q. どうやってゲームを実行してテストするのか？

• A. API リクエストから Device Farm Controller を通して指定されたステータスのデバイスを Device Farm またはオンプレミスで指定された通りのコマンドパラメーターで実行します。

• Q. プライベートなゲームサーバーと接続できる？

• A. VPC サポートのセクションで説明した通りです。非常に多くのゲーム開発者がこのことについて心配しますが構築された環境にはカスタマイズ可能な VPC 環境があり、デバイスがオンプレミスにあってもクラウド上にあってもセキュアにプライベートサーバーと接続することが可能です。

• Q. どんなアーティファクトやメトリクスを取得できますか？

• A. CPU メトリクス、ロードメトリクス、スクリーンショット、動画キャプチャ、ログのバンドリングなどをカスタマイズ可能な設定次第で取得できます。

• Q. この環境はセキュアですか？

• A. この質問は最後に必ずといっていいほどされます(笑)全てを VPC 内部に閉じることができ WAN を介さず内部的に動作するこの環境はセキュアであると言えますね。

• Q. スケーラブルですか？

• A. スケーラブルであることは Device Farm を利用する上での大きなメリットです。例えば、同じデバイスが後２０台必要になった場合、Device Farm のサポートチームにリクエストメールを送るだけで利用が可能になるのです。

Device Farm の新機能について

Device Farm の利用を始める前に、どのような要望が出てくるか少し考えてみましょう。クライアントの要望は大きく以下の三つです。

1. 独自のエンドポイントと繋げたい
2. 異なる環境から実行したい
3. カスタマイズしたい

１つ目の要望を満たすアップデートが以下です。VPC-ENI コネクティビティサポートで手動または CI 上などどこからでもセキュアにプライベートエンドポイントと接続が可能です。

２つ目の要望は様々な異なる環境から実行したいというものでした。この要望への答えとして以下のアップデートをご紹介します。

Device Farm へのアクセス方法として一番シンプルなのは AWS マネジメントコンソールからのアクセスで、次に AWS CLI コマンドと通じてアクセスできますが、その他のサービスはどうでしょう。Device Farm には大きなプラグインエコシステムがあり、Jenkins や Gradle を利用したい場合は App ストアからプラグインをダウンロードするだけで Device Farm との疎通が可能です。

さらに新しいアップデートとして Device Farm が Github Actions から直接利用できるようになりました。Device Farm を利用したテストを行うだけでなく、テスト結果から Github Issue を自動で作成することが可能です。

テストのトリガーにブランチへの Push やプルリクエストの作成時を指定できます。またはスケジュールされたタイミングでテストを実施することができます。

３つ目の要望はカスタマイズ可能にすることでした。

Device Farm でテストを実行する際、２つのパラメーターを渡します。１つ目はテストしたいアプリです。ネイティブアプリ、ハイブリッドアプリまたは Web アプリのいづれかです。次に２つ目のパラメーターにテストコードを渡します。これらのパラメーターを持ったリクエストを受け取った Device Farm はまず EC2 インスタンスを立ち上げます。ホストとデバイスは 1 0n 1 の関係になっており、仮に 100 台のデバイスをリクエストした場合、100 の EC2 が立ち上がり、それぞれが独自の環境で動作しテストを実行します。

最近は色々なライブラリや依存、テストフレームワークなどから最適なものを選ぶようになりました。そこで devicefarm-cli を導入し、ライブラリや依存のバージョンを柔軟に指定できるようにしました。

ここまで３つの要望に答えてきましたが更なる要望に応えるべく以下のアップデートも追加されました。

Android のドキュメントを読んでいると、新機能が追加されました、ただし ルーターデバイスまたはエミュレータのみアクセス可能ですという記述をよく身かけます。

または異なるバージョンの同じアプリをインストールしたい場合、ルーターデバイスでない場合同じ名前のアプリが存在する場合インストールができないのですがルーターデバイスを使う場合は上書きすることができます。

以下のアップデートでさらに細かい CPU のメトリクスやバッテリーの利用状況、ファイル名の上書きが可能になります。

Workshop の紹介

Device Farmを使ってみたい方には以下のWorkshopがおすすめです。

セッション動画